1.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ieeab24b7818f6d818c3922e4f5d9863a337e9a34
Code Smell Term: circular dependency
Code Smell Discussions:
1)	Reviewer: I would suggest using ds_util.build_datastore_path
2)	Developer: Unfortunately that would create a circular dependency between vm_util and ds_util modules.
Source Code URL: https://review.opendev.org/#/c/86038/2..3/nova/virt/vmwareapi/vm_util.py@168
2.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I1356163f103b962d62e1b63d0f68ff608073bd7b
Code Smell Term: circular dependency
Code Smell Discussions:
1)	Reviewers: would it be better to move this to a new file pbm_util ? In that case, we can use these methods in vm_util. Currently, it's not possible due to circular dependency.
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/66666/2..3/nova/virt/vmwareapi/volume_util.py@178
3.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I94e63159ee5539ed7b947614ff0ec87182f184a4
Code Smell Term: dead code
Code Smell Discussions:
1)	Reviewer: Is MEMPAGES_DEFAULT dead code? I don't see where it's being used.
Source Code URL: https://review.opendev.org/#/c/128006/25..26/nova/virt/hardware.py@42
4.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I399b812f6d452226fd306c423de8dcea8520d2aa
Code Smell Term: dead code
Code Smell Discussions:
1)	Reviewer: Pardon my ignorance. Won't this default to 900? Is the "or None" dead code?
2)	Developer: Hi Jesse,
or None will not be a dead code. In help message it is mentioned that 0 means wait forever. If service provider configures client_socket_timeout as 0, the connection will time out immediately and we get run time error while sending the request. In order to configure eventlet wsgi socket to wait forever, it should be set to None.
So, I have added  CONF.client_socket_timeout or None.
Please refer:
http://eventlet.net/doc/modules/wsgi.html
	Source Code URL: https://review.opendev.org/#/c/130843/1..4/nova/wsgi.py@120
5.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I0bf7535ae3f7d9e6820f8dc07075892953d80a78
Code Smell Term: dead code
Code Smell Discussions:
1)	Reviewer: if len(vdi_uuid_list) < 1: should be error case?
2)	Developer: It could be, its just not technically possible. I wondered about adding that in, but it seems much neater without?
3)	Reviewer: No need to add dead code if it's not possible.
Source Code URL: https://review.opendev.org/#/c/121177/7/nova/virt/xenapi/vm_utils.py@2073
6.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ifcfeb90e09a75fc25ac5fd4f18cfd69ea0b21f50
Code Smell Term: dead code
Code Smell Discussions:
1)	Reviewer: Why do you need that here? this is dead code, surely?
Source Code URL: https://review.opendev.org/#/c/82778/31..32/nova/compute/resource_tracker.py@463
7.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I432b0b0c09db82797f28deb5617f02ee45a4278c
Code Smell Term: dead code
Code Smell Discussions:
1)	Reviewer: Not sure this comment is correct - we're not 'recreating' domains at all here - this is about shutdown. Copy+paste mistake i guess.
2)	Developer: Yep - came from soft reboot ;-(
3)	Reviewer: I don't think the check old_domid != new_domid makes sense here. In _soft_reboot() it is necessary to make sure the newly booted instance is different from the old instance with the same name. Here we are only dealing with one instance, the one being shutdown, so this is dead code.
Source Code URL: https://review.opendev.org/#/c/68942/9..10/nova/virt/libvirt/driver.py@2103
8.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ia76552f49adf9b0d0128f08e3f99953560d8aa64
Code Smell Term: dead code
Code Smell Discussions:
1)	Reviewer: It looks like this patch makes this conductor method unused, as you allude to in the commit message.  How about removing the dead code from conductor.api and conductor.rpcapi in this patch?
2)	Developer: Dan pointed out that this is done in a later patch.  It's not worth the effort to squash it back to here now
Source Code URL: https://review.opendev.org/#/c/87019/5..6//COMMIT_MSG@13
9.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Id5de0e6843c1035235598a4d72a00b7555187fb4
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: hmm, so, I have a suggestion.. since this is only used by volumeops and it's would be best to keep the logic of utils classes as low as possible.. how about this:
    def detach_vm_physical_disk(...):
        self._get_mounted_disk_resource_from_path(path, class_name, res_sub_type)
        ...
    def detach_vm_hard_disk(...):
        ....
So, ISCSIDriver will call detach_vm_physical_disk and SMBDriver will call detach_vm_hard_disk.
2)	Developer: This will lead to quite some duplicated code, which IMO is not desired.
Source Code URL: https://review.opendev.org/#/c/129235/8..9/nova/virt/hyperv/vmutils.py@654
10.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I012ee5c118265e044ff41fb58b732728946ee85a
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: I think you can do function that remove duplicated code, something like that ->
    def _compare(self, exp_real):
        for exp, real in exp_real:
            self.assertEqual(exp['count'], real.count)
            self.assertEqual(exp['alias_name'], real.alias_name)
            self.assertEqual(exp['spec'], real.spec)
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/118391/14..16/nova/tests/pci/test_pci_request.py@176
11.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I57199273dcaf20b0b6618dfb436a92f04b139f52
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: I think its much cleaner to have a class method that specialises what needs to be done for v2 vs v2.1 rather than having if statements and duplicated code. But happy for this to be cleaned up later
Source Code URL: https://review.opendev.org/#/c/117688/5/nova/tests/api/openstack/compute/contrib/test_used_limits.py@78
12.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I9316dcedd65244c60d468b270311f032b45b051f
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: I'd prefer to combine this test and the one before it into a private test method with the force_tcg parameter passed in for the test and to do the different assertions on vfs.handle.backend_settings, otherwise there is a lot of duplicated code here.
Source Code URL: https://review.opendev.org/#/c/104262/5..6/nova/tests/virt/test_virt_disk_vfs_guestfs.py@56
13.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ib346b5739d11a7f1fc0a145673bb2701b4b59455
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: Is there value in having basically the same tests in here AND in test_configdrive?  They are both going through the spawn method on the driver right?  Or is one using vmops and the other is using the driver?  I just don't like duplicated code but if there is a reasonable justification for this I can be sold cheaply and easily.
2)	Developer: we need create_vm here to support a lot of the other testing in this method.  i agree it's duplicate code, but it's needed here too and this one is more complex that the test_config one.  Ideas for consolidating these?
Source Code URL: https://review.opendev.org/#/c/86442/55..56/nova/tests/virt/vmwareapi/test_driver_api.py@466
14.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I433cbbdbef4ac3c01a3e2b6ed5cf092a5cce6372
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: A lot of duplicated code between the 3 test, perhaps a future refactor.
2)	Developer: Yeah, it looks bad in there.
Source Code URL: https://review.opendev.org/#/c/85037/3/nova/tests/scheduler/test_host_filters.py@532
15.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I9b77a50206d0eda709df8356faaeeba35d232f22
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: Duplicated code, see line #178-189. It caused pylint testing failure.
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/59149/8..9/nova/virt/imagehandler/base.py@59
16.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I9b77a50206d0eda709df8356faaeeba35d232f22
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: Duplicated code
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/59149/8..9/nova/virt/libvirt/imagebackend.py@105
17.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I650a8f191dea5eab5b4b1828f0b9f65e33edea2a
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: Everything above this point could be replaced by a pretty tight loop, something like:
 types = {'name': str, 'members': list, ...}
 for key in expected_fields:
     if not isinstance(subbody.pop(key, None), types[key]):
        raise ....

Otherwise it's a lot of duplicated code. Then after this loop, you put your:
 if subbody:
raise # Extra things provided
	Source Code URL: https://review.opendev.org/#/c/62557/29..30/nova/api/openstack/compute/contrib/server_groups.py@309
18.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I63109110f373324e7e81841f42a6cb21127c3386
Code Smell Term: duplicated code
Code Smell Discussions:
1)	Reviewer: Lots of duplicated code here.
I think you could do something shorter and 	 like:
if type(opt) in [cfg.StrOpt, cfg.ListOpt, cfg.FloatOpt, cfg.IntOpt, cfg.BoolOpt]:
res.append(type(opt)(override, default=opt.default, help=opt.help)
2)	Developer: This way we don't even need the if type(opt) ...
done, thanks
	Source Code URL: https://review.opendev.org/#/c/58480/13..14/nova/scheduler/policy_configuration.py@76
19.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I07e0b5c034556c0b5035c7dc754920f74982a8d1
Code Smell Term: long parameter list
Code Smell Discussions:
1)	Reviewer: should we have a variable for a description of the disk (i.e. swap, ephemeral, primary), this can be useful in logging, or is it suffices to tell them apart by the disk name?
2)	Developer: The reason I wouldn't want to do that is the _create_virtual_disk method doesn't know what you are going to use the disk for. I would be introducing a variable (this already has an obscenely long parameter list) just for the purpose of logging something that may or may not be interesting.
By analogy:
When I add 2 + 2 the adder doesn't know *why* the addition is happening, it is performing an atomic function. I have to find the reason for the addition from the surrounding context.
I would call this a separation of concerns SoC issue: 
http://en.wikipedia.org/wiki/Separation_of_concerns
This isn't really that strict a rule though, so if the reason the disk is being created is a deep enough concern that might be a good enough reason to break SoC and mix concerns on purpose.
BTW: this patch needs tests. I won't have time to write them until much later.
Source Code URL: https://review.opendev.org/#/c/72719/2/nova/virt/vmwareapi/vmops.py@185
20.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I2755c59b4db736151000dae351fd776d3c15ca39
Code Smell Term: shotgun surgery
Code Smell Discussions:
1)	Reviewer: I'm really not happy with polluting the destroy + cleanup methods with arbitrary driver specific data blob like this.
The pre-existing 'destroy_disks' parameter here is involved in migration and set appropriately by the compute manager. I really think a similar approach is require here. ie any new parameter to 'cleanup' should take the form of a functional instruction of what the required behaviour of the cleanup method is.
ie IMHO this should be 'delete_instance_files=True' as a parameter, since the semantics of that nicely match the standard 'delete_instance_files' method in the virt driver API.
2)	Developer: We already had this discussion in patch set 22, the conclusion was that, even if what you're asking for were a valid approach, it would expand the scope of this patch too far beyond the bug in question.
If you really insist on pulling that discussion out of the freezer after a month and a dozen patch revisions (which by itself is another indicator that the discussion belongs in a blueprint, not bugfix review comments), here's where we left it, from my perspective.
I think that polluting signatures of methods of the parent class with implementation specific parameters (and delete_instance_files is as libvirt specific as it gets) is a recipe for the shotgun surgery anti-pattern. You don't have to go further than this very patch to observe the impact of that anti-pattern in how (at your own request in patch set 21) I had to touch all virt drivers to fix a libvirt specific problem.
Another argument I already made in patch set 22 that is worth reiterating is that the amount of driver specific information passed over RPC is likely to grow as drivers mature. And every time you need to change what you pass between two instances of the same driver, you'd have same amount of shotgun surgery all over the place, unless you encapsulate implementation specific details away from upper layers so that only the driver itself has to be changed.
	Source Code URL: https://review.opendev.org/#/c/91722/34..35/nova/virt/driver.py@335

1.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I4dff5267902362057cc5ee18357539b7192782cb
Code Smell Term: circular dependency
Code Smell Discussions: 
1)	Reviewer: Can we push this logic into flavors.extract_flavor so it's more re-usable from there?
2)	Developer: You end up with a circular dependency, I forget where exactly. However, this is why I went ahead of time and converted every extract_flavor to instance.get_flavor when using an object.
3)	Reviewer: OK, well that blows, but I guess given the below reply I'm not as concerned.
Source Code URL: https://review.opendev.org/#/c/135700/40..41/nova/scheduler/utils.py@59
2.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I40a25abe1ce96f1dc7d78ec46c948c8db451632b
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This whole logic looks complicated and I don't really understand how it works.
But.
If you say that the Volume's vmdk was moved (L468), why not have something like:
    volume_vmdk_moved = not self._check_vmdk_exists(....)
    if volume_vmdk_moved:
        self.detach_disk_from_vm(....)
        # this I don't get, if the vmdk was moved, how can you relocate the
        # volume, having the old volume_ref?
        self._relocate_vmdk_volume(volume_ref, res_pool, datastore, host)
    else:
        self._relocate_vmdk_volume(volume_ref, res_pool, datastore, host)
        self.detach_disk_from_vm(volume_ref, instance, original_device, destroy_disk=True)
Even this seems unnecessary, really. You already know that it was moved, according to the L450, causing the try to always fail. This means the else I've written now is totally useless / dead code.
2)	Developer: I think some of your confusion will be cleared if you understand the fact that volume in this case is a VM with an attached vmdk. This VM is called backing VM and is never powered on. During volume attach, we attach the volume's backing VM's vmdk to the nova instance.
I understand that your logic is simple and I would like to include it. But the problem is, there is no API in FileManager or VirtualDiskManager to implement self._check_vmdk_exists(....)
>this I don't get, if the vmdk was moved, how can you relocate the volume
We can, because we are relocating the backing VM after removing its disk device.
When SDRS moves the volume's vmdk, we end up with a backing VM with a virtual device of type VirtualDisk which points to a non-existing device backing (vmdk file). The only way to repair is to remove the virtual device, relocate the backing VM and attach the vmdk file in the new location.
I think we can add some more comments in _consolidate_vmdk_volume to make things clear. Also, I will try to implement _check_vmdk_exists using some existing methods even though it's not meant for checking file existence.
Source Code URL: https://review.opendev.org/#/c/159738/6..7/nova/virt/vmwareapi/volumeops.py@482
3.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ibed4212df0e29598d98071b8f00cb0dbcbedcabc
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: my concern here is that this may break something - as in the past if we had columns_to_join=None then we would expect to get the systems_metadata.
2)	Developer: I have tested this and it does not break anything because this method is not called with columns_to_join as None anywhere.
It is only called with columns_to_join as None from conductor.manager but that code is not used any more and will be removed in major rpc version bump.
3)	Reviewer: I've just done a quick audit, and I think this is ok. This function is used in 2 places: conductor and InstanceList. The former has no current callers itself, so we can discount that. InstanceList.get_active_by_window_joined is called by the _instance_usage_audit periodic task, which requests columns explicitly. The only other caller is _tenant_usages_for_period, which is the focus of this patch.
In the spirit of removing obtuse, dead code, I'm in favour of this regardless.
Source Code URL: https://review.opendev.org/#/c/159062/1/nova/db/sqlalchemy/api.py@a2239
4.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ia8ae49c5a38b217f19632a1ac40343ec9e608796
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Like I said per IRC, I think we need to consider deferring the SG control to an external tool whatever the driver is, just because it's intended to be exposed as a REST API resource.
Here, we need consistency between drivers and have the same level of control, even if we consider ZK trustful.
2)	Reviewer: So while I agree that force_down needs to work for all drivers regardless of the fact that it's useless for the usecase we ahve in mind here, ZK drvier in nova is junk. it's not used anywhere, and is planned to be completely replaced in the very near future.
Blocking a useful feature on keeping what is basically dead code compatible with it is not something we should be doing.
3)	Reviewer: So, lemme be clear : I would be +1 if the if branch would be done directly in the API base module, ie. https://github.com/openstack/nova/blob/master/nova/servicegroup/api.py#L87 
because then it wouldn't need to be discussing about the ZK nor the MC drivers and would make it clear that whatever the driver is, it wouldn't be called if forced_down
4)	Reviewer: I'm OK with this - but don't really care for the ZK driver so I'm ok with the code as is too. I could see arguments for both - if we have a driver that's reasonably fast in determining failure/partition, it's not unreasonable to make it ignore what is essentially a crutch for weaker drivers.
But I am not sure these details are at all important with the current state of play so would prioritize merging this in any form over deeper discussion on some of these issues.
Source Code URL: https://review.opendev.org/#/c/197063/11..12//COMMIT_MSG@16
5.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I8326596696cbb030ae95d17f3dd430d05279081a
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Dead code? Wouldn't be cleaner to just leave this out and deal with any bugs that might occur / have a test to validate this cannot happen.
2)	Developer: Well not exactly dead - it might happen if the scheduler does not have the proper filter configured, so it's not a completely unlikely condition and it's better to fail then to do the wrong thing silently.
Some debug would be good tho.
Source Code URL: https://review.opendev.org/#/c/159106/6..7/nova/virt/libvirt/driver.py@3442
6.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I8326596696cbb030ae95d17f3dd430d05279081a
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Dead code? Wouldn't be cleaner to just leave this out and deal with any bugs that might occur / have a test to validate this cannot happen.
2)	Developer: Same as above
Source Code URL: https://review.opendev.org/#/c/159106/6..7/nova/virt/libvirt/driver.py@3803
7.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I8326596696cbb030ae95d17f3dd430d05279081a
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Dead code? Wouldn't be cleaner to just leave this out and deal with any bugs that might occur / have a test to validate this cannot happen.
Source Code URL: https://review.opendev.org/#/c/159106/6..7/nova/virt/libvirt/driver.py@3808
8.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I7cb5ab3e43a1e3bd7ccba0480053361743f859b2
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Are we not fixing it here for a reason?
2)	Developer: as far as I can tell this is actually dead code now. I think it's removable.
Source Code URL: https://review.opendev.org/#/c/159824/9..10/nova/api/openstack/auth.py@93
9.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I13a04bdc78b92de69b81333eeb529cadc4d3c856
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Looks like copy-paste of above and, more importantly, dead code.
2)	Developer: yes, sorry for that.
Source Code URL: https://review.opendev.org/#/c/130449/4..5/nova/api/openstack/compute/plugins/v3/fping.py@151
10.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ieb9a03d308495be4e8c54b5c6c0ff781ea7f0559
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: As mentioned on the other file - while put this in if it's going to be dead code?
let's leave it out for a different patch?
2)	Developer: This commit has 2 capability:
a) Libvirt Secret framework for RBD, iSCSI and Volume
b) iSCSI built-in support with a)
So, I want not to delete them. Please check my comment in the next file.
Source Code URL: https://review.opendev.org/#/c/135854/15..16/nova/virt/libvirt/host.py@687
11.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I14aba8b14b7036a09a8dde8235fd4345af4da510
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: Lots of duplicated code and if conditions here making it painful to follow. Why not create some helper methods to avoid this? For example, you could have something like _ensure_hot_plug_is_available, thus greatly simplifying the code.
This will also simplify a lot the related unit tests.
Source Code URL: https://review.opendev.org/#/c/138255/15..16/nova/virt/hyperv/vmops.py@712
12.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I62c0800f68d8fd89fed98eea9e3f95d1adbe9d7f
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: I think you are missing the volume delete in the case of delete_on_termination.
Now I have a feeling we have way way too much duplicated code here:
https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1831
Can we share code here? somehow?
What about with here too really:
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2275
and this bit:
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2302
2)	Reviewer: I don't think we're supposed to delete the volume, we only do that if we created it, which is only in the image/snapshot/blank cases, see how _call_wait_func is used below.
I agree that the code in _shutdown_instance in nova.compute.manager could probably be moved into this module, but at this point in the release I'm not sure we want to do that now - we could refactor and consolidate that code in a follow up change.  That kind of refactor in the bug fix also makes this harder to backport (thinking ahead to mitaka if this doesn't land in liberty, we'd want to backport to stable/liberty).
3)	Reviewer: I think we should catch any exceptions from volume_api.detach and pass.  If volume attach didn't complete and we call volume detach here, it could cause exceptions.  Not sure if every Cinder driver ignores it if we try to detach a volume that is not attached.
4)	Reviewer: I think it's OK given we're in a with excutils.save_and_reraise_exception(): block, so we are already going to be raising the original volume_api.attach failure - which is how we got here.
5)	Reviewer: @John - I've opened bug 1497343 to track consolidated the duplicate detach code.
6)	Developer: >If volume attach didn't complete and we call volume detach here, it could cause exceptions. 
There was exception handling in previous patch sets. But the following Cinder patch ensures that there will not be any exception if the attachment is not found during volume detach.
https://review.openstack.org/#/c/212193/
>Not sure if every Cinder driver ignores it
The driver detach happens after the db query to retrieve the attachment. If there is no attachment, we ignore the exception and return without calling the driver detach.
7)	Reviewer: Thanks Vipin.  I'm more thinking about when db and array are out of sync.  So it says attached in db, but it is not the case on the array.  self.driver.detach_volume(context, volume, attachment) could still throw exception.  I did run into the situation when db and array are out of sync when initialize_connection times out, but I haven't seen that in this particular code path that you are covering.  This is fine as the original exception will be raised any way.
Source Code URL: https://review.opendev.org/#/c/186742/11/nova/virt/block_device.py@303
13.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I156a1c3cf3e31f34cea5e240b14a9575e9e45239
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: nit: you could probably somewhat easily combine the majority of this test and the one before it into a private method but pass a flag to tell it whether or not you're doing cells, and then within that private method you just mock the keypair object or cells calls as appropriate, then we wouldn't have so much duplicated code here.
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/197514/12..13/nova/tests/unit/test_metadata.py@404
14.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I8505cb71de2cf9d771fa1fe9eddce3d39158e74f
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: Could you refactor this "if" to a separate method like "is_hw_vif_multiqueue_enabled(self, image_meta)". It's just duplicated code with the if in _get_virtio_mq_settings above. And it would make the code more readable!
2)	Developer: Next will have only one check.
Moreover, all of this if statement is going to be replaced with ImageMetaProps object, when this series will be merged: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:virtimageprops-17,n,z
IMHO, It is better to keep this as one part to replace it easily.
3)	Reviewer: makes sense
Source Code URL: https://review.opendev.org/#/c/128829/7..8/nova/virt/libvirt/vif.py@375
15.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I33d11bf29e7e7a29711e374fdce42a1f8b35f247
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: connection info is used by multiple tests. Wouldn't it be better to define it as a constant in order to avoid duplicated code?
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/139797/13..14/nova/tests/unit/virt/hyperv/test_volumeops.py@172
16.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I2b9c9bdfc2456bb66df06e85c1d59fbd9a50ec30
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: A minor thing is, not sure if we can have api like objects.NUMATopology._from_db(), which will wrap all such legacy/new format check in the NUMATopology itself, and the caller don't need care for them? It will reduce duplicated code at host_manager, and will make easier cleanup when major version bump.
Source Code URL: https://review.opendev.org/#/c/152689/1..2/nova/objects/compute_node.py@170
17.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I38bcdf85a0d9d3c72b7b308a207ce9bad65aaf60
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Developers: This is duplicated code and should be done decomposition.
Source Code URL: https://review.opendev.org/#/c/161283/1..2/nova/tests/unit/virt/xenapi/test_xenapi.py@1543
18.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I38bcdf85a0d9d3c72b7b308a207ce9bad65aaf60
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Developers: ditto about duplicated code.
Source Code URL: https://review.opendev.org/#/c/161283/1..2/nova/tests/unit/virt/xenapi/test_xenapi.py@1660
19.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I38bcdf85a0d9d3c72b7b308a207ce9bad65aaf60
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Developers: ditto about duplicated code.
Source Code URL: https://review.opendev.org/#/c/161283/1..2/nova/tests/unit/virt/xenapi/test_xenapi.py@2312
20.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I38bcdf85a0d9d3c72b7b308a207ce9bad65aaf60
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Developers: ditto about duplicated code.
Source Code URL: https://review.opendev.org/#/c/161283/1..2/nova/tests/unit/virt/xenapi/test_xenapi.py@2436
21.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ib31c4f806e30a8b33669d5a15bd1578050c7e352
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: ditto
2)	Developer: Same response as above.  Note that we would have to have two separate constants anyways, so it wouldn't actually remove any duplicated code.  Currently the two lines are identical, but there's no guarantee that the arch list for numa and hugepages will stay the same.
Source Code URL: https://review.opendev.org/#/c/170780/10..11/nova/virt/libvirt/driver.py@4744
22.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ib6134fee5d7ce7096ca7a5eff6e22597bda6ee88
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: so many duplicated codes in these test case. 
you can refine them into a general function.
2)	Developer: Having a general function doesn't reduce the code lines much, we could move all the common code into setup function, sounds fair ?
Source Code URL: https://review.opendev.org/#/c/149945/2..3/nova/tests/unit/api/openstack/compute/contrib/test_floating_ip_dns.py@486
23.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ia53afcbd0294f9e864339230338b505bff2e7ca1
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: these two test case are duplicated codes. But it is only two. So it is OK to me. 
you can refer this patch:
 https://review.openstack.org/#/c/149529/6/nova/tests/unit/api/openstack/compute/contrib/test_admin_actions.py
2)	Reviewer: nice point, I also am OK for *two* and I don't -1 on current code.
Source Code URL: https://review.opendev.org/#/c/155678/2/nova/tests/unit/api/openstack/compute/contrib/test_rescue.py@223
24.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I2e78831b4ed86623bb1061e6050ca0010944f457
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: This seems to be used quite often, why not put it in a helper method to avoid duplicated code?
Source Code URL: https://review.opendev.org/#/c/143114/24..26/nova/tests/unit/api/ec2/test_cinder_cloud.py@1098
25.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Iab89aba13ec00c9ed8f92940a52486bf2dab1a15
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: This method has a lot duplicated code of `_apply_instance_name_template`. The differ in the use of `index` and the CONF parameters. With a bit refactoring only one method would be necessary I guess.
2)	Developer: I thought to make / leave this separate in case one wants to configure the multi_instance_name_template different to that of single instance.
Source Code URL: https://review.opendev.org/#/c/116472/3..4/nova/compute/api.py@577

1.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I87769999839871c1a8d29c9013789d2611b8bccf
Code Smell Term: bad naming
Code Smell Discussions: 
1)	Developer: Here
2)	Reviewer: It's a horrible design, compute/SecurityGroupAPI is defining a totally different API than network/security_groups... This multiple inheritance should be removed.
3)	Developer: Maybe, however that is out of scope for this change.
4)	Reviewer: Let see what other contributors think, from my point of view you are doing so "many" changes not related in one commit because a bad design. This class should not inherits from SecurityGroupBase.
If you remove that point you can just update SecurityGroupAPI.get_instance_security_groups() without update methods in network/security_groups classes. Then create an other commit to do that clean.
5)	Developer: But they do in fact implement the same interface. Depending on if you run nova-network or neutron you set CONF.security_group_driver to "nova" or "neutron" and one of nova.compute.api.SecurityGroupAPI() and nova.network.security_group.neutron_driver.SecurityGroupAPI() is chosen as the security group driver. See nova/network/security_group/openstack_driver.py
6)	Reviewer: Hum, we have a driver interface and an API interface which are different from my point of view. Example, virt drivers and compute api do not share same interface. We have a specific driver interface and api interface and they are not sharing same base class even if some methods shared same name.
7)	Developer: Ok, not driver, just API. I think this is just matter of bad naming/spread out placement.
The SecurityGroupAPI defined in nova.network.security_group.security_group_base.SecurityGroupBase has implementations in nova.network.security_group.neutron_driver.SecurityGroupAPI and nova.compute.api.SecurityGroupAPI. Although the name of the neutron API implies its a driver, its not.
This is exactly the same way the NetworkAPI works with a Base class and two implementations, one for nova-network and one for neutron.
Callers of the SecurityGroupAPI expects identical method signatures whether the used api is Neutron or Nova so I really can't change one without the other or things will break. A call to get_instance_security_groups() must be valid for all APIs.
Source Code URL: https://review.opendev.org/#/c/259813/3..4/nova/compute/api.py@3823
2.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~If04f732a04588f070920bbd918531faf28fb4de4
Code Smell Term: Circular Dependency
Code Smell Discussions: 
1)	Reviewer: Nit: this should start with a NOTE (edleaf) I think?
I am cool with this though, for the reason you state here. We could make vm_states use this constant, but that feels like overkill?
2)	Developer: Added the NOTE.
I tried every permutation I could find to resolve the circular dependency, but they always got imported out of order. This was the best compromise.
Source Code URL: https://review.opendev.org/#/c/309196/4/nova/conf/api.py@79
3.     Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~If04f732a04588f070920bbd918531faf28fb4de4
Code Smell Term: circular dependency
Code Smell Discussions: 
1)	Reviewer: What creates the circular dependency? Module [1] which contains all the constants doesn't import anything else. I assume my Python knowledge has a deficiency here. 
[1] https://github.com/openstack/nova/blob/master/nova/compute/vm_states.py
2)	Developer: I have to import that module to access those constants. That file is OK, but the module itself triggers import references that cause the circular import.
Source Code URL: https://review.opendev.org/#/c/309196/5..6/nova/conf/api.py@80
4.	Code Change URL: 
Code Smell Term: circular dependency
Code Smell Discussions: 
1)	Nit: this should start with a NOTE (edleaf) I think?
I am cool with this though, for the reason you state here. We could make vm_states use this constant, but that feels like overkill?
2)	Developer: Added the NOTE.
I tried every permutation I could find to resolve the circular dependency, but they always got imported out of order. This was the best compromise.
Source Code URL: https://review.opendev.org/#/c/309196/4..6/nova/conf/api.py@79
5.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I4e333e73ddfd45c045b9d32dac1506fc25858c4d
Code Smell Term: circular dependency
Code Smell Discussions: 
1)	Reviewer: Where does this get called/used?
2)	Reviewer: What happens when we have to add this for os-vif also?
3)	Reviewer: Looking at the privsep code, privsep_context is a single entry:
https://github.com/openstack/oslo.privsep/blob/master/oslo_privsep/daemon.py#L485
Won't that have to handle multiple entries (list or multistr opt) for when we have os_vif.privileged.default?
4)	Reviewer: If I'm reading this correctly, the privsep-helper is used here:
http://git.openstack.org/cgit/openstack/oslo.privsep/tree/oslo_privsep/daemon.py#n338
And the helper_command is defined in nova.conf, which is provided, and set in the devstack change here:
https://review.openstack.org/#/c/277696/3/lib/nova
It all seems a bit like a circular-dependency, unless I'm not following this correctly.
Just trying to understand this some more before we land it.
5)	Developer: Yes, this command is invoked in the depths of oslo.privsep, in response to the singleton created/configured in os-brick here: https://review.openstack.org/#/c/277224/21/os_brick/privileged/__init__.py
It is expected that most "projects" that use oslo.privsep will want their privileged code running with a different set of privileges/uids, and so there will probably be several (I'd guess ~3) lines like the above in a diverse project like nova.  These lines will each have a different --privsep_context (and I think rootwrap also requires the first field to be unique, but it is otherwise ignored).
The abstract purpose of the line above is for the administrator to declare that:
a particular collection of python code (python environment used for the privsep-helper command) and
oslo.config configuration (--config-file)
is secure (writable by root only) and trusted to be run with elevated privileges (as granted by rootwrap in this example)
and provide access to the functions/permissions defined by the --privsep_context defined in that python code and config.
The big difference from rootwrap that you can see here is that in rootwrap the exact command lines to be "trusted" had to be repeated in rootwrap filters _and_ in the python code that generated the command lines.  In privsep, the "trust" is delegated to the trusted python import path.
I think the "circular dependency" tingling in your spider sense is the two paths (python singleton, and rootwrap filter entry) that both repeat the combination of code and context name.  Unfortunately this is required because we start nova (and other openstack services) with zero privileges and expect them to magically gain them via sudo/rootwrap halfway through the callstack.  This necessarily requires a somewhat-duplicated sudo/rootwrap config somewhere with a narrow definition of what should be allowed, because you wouldn't want just any code to be able to gain root in this way.  Security exploits abound because it is hard to make these two descriptions match - see the "chmod" entry earlier in this rootwrap filters file for an example that can be trivially exploited.  If you're curious, an alternative to all of this is the usual Unix model of _starting_ a daemon with all required permissions, doing setup, and then dropping privileges before processing queries - if we were to migrate nova to this method of invocation, then we wouldn't need the above rootwrap entry (nor sudo) at all.  oslo.privsep allows us to move to that usual Unix model, if anyone would like to make changes to the way nova is deployed ;)
I encourage you to read the oslo.privsep spec if you haven't already, since it is the best place for an overview of how the pieces fit together (or at least if it isn't clear there, then we should fix that).
6)	Reviewer: Thanks, this plus the response in the mailing list helps:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090172.html
As for the spec, I tried to read through most of it, but my eyes started to glaze over before really getting into implementation details. So probably the reason I was really asking about a lot of this here (in this dependency chain series anyway) is that there is this actual series of patches with examples, so it's easier to form in my head how they are related.
Source Code URL: https://review.opendev.org/#/c/277670/5/etc/nova/rootwrap.d/compute.filters@220
6.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I51585302e898251e26cbf311aeac38a0ec329001
Code Smell Term: coding by exception
Code Smell Discussions: 
1)	Reviewer: This can be a simple if-else instead of coding by exception.
2)	Developer: Please check ps-5 for details, Roman proposed to change code this one, as it's atomic action instead of 
if a in dict:
  ...
3)	Reviewer: okay, makes sense
Source Code URL: https://review.opendev.org/#/c/287997/7..8/nova/virt/libvirt/driver.py@6446
7.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I93a4ac78aaf0ac0c0a99a27ef7e145949f706d45
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Might be nice to add the virt_type and CPU arch to the debug message here...
2)	Developer: As I have to respin for the issue you found in line 4401, I'll add that in ps3.
3)	Developer: Funny, I wanted to write a unit test for that and discovered that I will never run into this case because of lines 4369 + 4376. Assumed there is a virt_type == "faked-virt-type", then line 4369 will be hit. Assumed there is virt_type == "qemu" and cpu_arch == "markus-z-cpu", then line 4376 will be hit. 
At first, I added that out of my habit to always have a else path...
Long story short, I'll remove this else path which is dead code.
Source Code URL: https://review.opendev.org/#/c/407120/2..3/nova/virt/libvirt/driver.py@4380
8.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I45ac06eae0b1949f746dae305469718649bfcf23
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: I just checked the code in libvirt and its python bindings. 'cur' and 'end' aren't pointers in virDomainBlockJobInfo; they're unsigned long long. Consequently, they can't obviously represent 'unset'. Sure enough, checking in the libvirt bindings they are set unconditionally in libvirt_virDomainGetBlockJobInfo(). This means that the existing code using .get() is actively misleading.
I'm definitely -1 on changing dead code as it makes it harder for the maintainer to find the original intent in git history. I would prefer that you changed these lookups to be unconditional, which correctly represents the data structure. However, if you just want to leave them alone (i.e. leave it with a default of 0) I'll submit a follow-on patch. I think this is a reasonable change to make in this patch, though.
2)	Developer: Ok. I left it unchanged here and I will propose another patch to change all those parameters to be unconditional
Source Code URL: https://review.opendev.org/#/c/363926/5..6/nova/virt/libvirt/guest.py@661
9.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I85b2b41d919ed6987d4c9288905ccce49c10c81f
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Works for me, I would have probably had a base dict and then popped the other things out of it for 2.36, but this is fine.
2)	Developer: right, this is optimized for delete. So it's easier to drop the dead code in the future.
Source Code URL: https://review.opendev.org/#/c/356694/1..2/nova/api/openstack/compute/used_limits.py@45
10.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I7755c39480d329ba8216d99586c5e94b69e67e6d
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: All options in this file are already deprecated, I think its worth to take out this flag rather than raising a separate patch for this. Ping John and he will +2 again on your next patch.
2)	Reviewer: So the idea of this flag is also to check if we can remove them already.
In this case, I am not sure we can remove these, but we might need to look at deprecating some other configuration options, so we are actually able to remove these.
3)	Reviewer: So my assumption was that we are not going to remove any deprecated option from Newton anymore, as it has more code impact and we don't want that at this moment. Only deprecate by setting the flag if required and remove in next cycle.
4)	Reviewer: So I dug a bit further, turns out its just dead code now, that this is configuring, so we should be clear to remove this next time.
5)	Reviewer: Ok, Thanks for the info. I will raise a patch to remove these options, if these are deprecated in M or before.
6)	Reviewer: Looks like these options were deprecated in this cycle only. Even though not used in code anymore, we should remove these in next cycle?
Source Code URL: https://review.opendev.org/#/c/351851/3..4/nova/conf/s3.py@1
11.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ibc44228aeae94c17353af7fccfcfb2c11b2e9190
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This can be done at schema with "maxItems" on array type.
2)	Reviewer: After discussion with Alex got to know that for better msg you want to validate here.
But L113 decorator does the validation and in case of invalid tag, I do not think it will come to this point.
seems like dead code?
3)	Developer: In L113 we have a schema.update_all. This schema validate *only* that in body we have an array of strings and this array named 'tags'. 
All other validation like max len, max count or symbols ',' and '/' I want to check manually for better error message because I think that error message like "Validation error: string 'tag,1' is not like regular expression '^[^,/]*$'" is awful. The end user may not know what it is.
4)	Reviewer: Yea, I agree on error message. but that's something we have for all APIs doing validation by schema.
Current way makes attribute validation back to python code from schema which we wanted to avoid for v2.1 (which was solved from v2->v2.1 using schema validation)
I feel we should have these validation in schema only otherwise schema validation becomes very week and we endup having those back to python code.
5)	Reviewer: So I agree with gmann, we should probably add this into the validators, and instead fix the validators to have better error messages, doing something like this: https://review.openstack.org/#/c/288260/2/nova/api/validation/validators.py
Now if were not on patchset 127, I would probably ask for us to move this to validation, and do a follow up to fix the error messages.
Either way, lets fix this up in a follow up patch?
6)	Reviewer: Ok, I agree on that.
Source Code URL: https://review.opendev.org/#/c/128940/127/nova/api/openstack/compute/server_tags.py@135
12.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I55c522e23f1a8924377c8dee6ecf298b545b7fb6
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: I also had this way before, but this way seems a little dangerous against keeping the principle of microversions.
On this way, the objects layer changes would affect REST API layer unintentionally, and it would be easy to forget microversioning that.
In addition, we need to check available parameter values in objects layer. That seems unreadable on that.
I agree with it is nice to remove duplicated code as possible, but this way seems over-optimization and sometime duplicated code will help the readability.
So it is nice to keep enum here and change the following destination_type to enum instead.
2)	Developer: Yes, this is very nice point. We should have schema as raw as possible. i will change.
Source Code URL: https://review.opendev.org/#/c/407886/1..2/nova/api/openstack/compute/schemas/block_device_mapping.py@29
13.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ie748709cda9e860f4e198fe25e61ccfd14d86e09
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: Can't you refactor this to use the new methods below and remove all the duplicated code? It would be nice to prove that the new methods work here by using them in this method, even if you're going to remove it at the end of the series.
Otherwise, we don't get validation that the new stuff (really) works until later when we start using it. It would be a lot better to avoid a bit inflate/deflate operation if we can help it, IMHO.
2)	Developer: Sure, I can do that for some of the trivial helpers, but not for some of the big picture stuff b/c of the way it cuts across cache/driver/backend.
Like you, I would prefer the added confidence. I had been making sure not to touch the old code b/c I thought that's what the reviewers would prefer. Happy to hear I can go ahead and make changes to it though.
Thanks for the review!
3)	Developer: I refactored some of the trivial stuff out of the to-be-deleted code, but that's about all I can do without also changing the driver code since this isn't a straight forward refactor (the responsibilities/boundaries have changed).
Source Code URL: https://review.opendev.org/#/c/317689/12..13/nova/virt/libvirt/imagebackend.py@1028
14.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Idf4086303baa4b936c90be89552ad8deb45cef3a
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: This code does not really help with testing changes related to RBD and is already covered by test_unrescue.
You can also avoid duplicated code by adding private method with all test code. Before calling private method you can mock RBD related methods, set CONF.libvirt.images_type to RBD and then validate mock.
Source Code URL: https://review.opendev.org/#/c/314928/1..2/nova/tests/unit/virt/libvirt/test_driver.py@15160
15.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ib026009be41744ab6057133493829b8e9e61972d
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: This is duplicated code, we should probably have a little private helper method for this so it can be re-used in both places.
Source Code URL: https://review.opendev.org/#/c/284674/10..11/nova/virt/libvirt/driver.py@6920
16.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ib6ff12b2710143798c1c29376edd9c1364d451b9
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: Should we put this bdi in a common place to avoid some duplicated code?
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/246299/10..11/nova/tests/unit/virt/hyperv/test_migrationops.py@282
17.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I5b7dcee81bf37272a012fdfb0c5c8e8c2305045e
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: It is much more useful to provide a new property 'available' in this object that represents `(total*allocation_ratio)-reserved-used`.
The logic to calculate available resources is redundant in current scheduler:
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/disk_filter.py#L46-L48
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/ram_filter.py#L51-L53
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/core_filter.py#L59
2)	Reviewer: Sorry, it's `(total - reserved) * allocation_ratio - used`
3)	Reviewer: Yes, I agree that having a calculated property on the object would be cleaner.
4)	Reviewer: Elaborating: a common need with this object is to see how much is available. Knowing how much is used may be of interest in some cases, but in many more the concern is "Are there enough Resource X". So what Yingxin is proposing (if I read it correctly) would be to add a read-only property to this object that will "return" the result of the calculation in his second comment above. As things currently are proposed, any code that uses this object would have to duplicate this calculation if it needed to know how much of Resource X was available. By providing a property that handles that, you eliminate the need for duplicated code.
5)	Developer: Thanks for the clarification Ed, my confusion yesterday seems to stem from me thinking that the suggestion was to replace the 'used' field with an 'available' field, not add it.
Adding it as a property makes good sense.
6)	Reviewer: I tend to agree with replacing the 'used' field with 'available' field, as well as replacing 'total' field, 'reserved' field and 'allocation_ratio'.
If this class is only used in scheduler service, there's actually no need to expose 'total', 'reserved', 'used' nor 'allocation_ratio' fields according to my current understanding during scheduling.
The only important fields are:
1) 'available' field for CoreFilter, DiskFilter, RamFilter, DiskWeigher, RAMWeigher and scheduler cache consumption.
2) 'exact_available' field for ExactCoreFilter, ExactDiskFilter, ExactRamFilter and scheduler cache consumption.
3) 'min_unit', 'max_unit' and 'step_size' are necessary to check resource consumption in scheduler.
7)	Developer: The primary purpose of the class is provide a way to encapsulate the representation of resources in the placement API: https://review.openstack.org/#/c/293104/
When you GET a resource pool from the api it includes a resources element that is a dictionary of resource class keys, with values that come from the ResourceUse object.
In that sense all the fields are important, because all the fields are needed in the representation as they are there for information purposes, not calculation.
In the scheduler, the corresponding fields are expected to be used in SQL calls, not via nova objects.
Source Code URL: https://review.opendev.org/#/c/284963/46..47/nova/objects/resource_provider.py@496
18.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Id7a71b2eb46ea7df19e7da0afbc0eafa87cac965
Code Smell Term: spaghetti code
Code Smell Discussions: 
1)	Reviewer: In a point of view of OO that looks really strange... It's clearly a hack. We add a method here because a child. I don't think it's the good way to fix that, we should verify which object it is before to call wait that is because we know exactly what we do...
2)	Developer: I agree that it's not really proper, but sometimes hacks are justified. There are performance implications with isinstance. When discussed on irc, this approach was preferred. It's also worth noting that this is the approach that was originally used years ago, and then mistakenly removed a few months ago causing this regression issue.
3)	Reviewer: Yes that is the point, because that looks like a hack in few week somebody are going to push a new patch to remove that unnecessary method. Really it's not how we should fix it. What is the problem with isinstance ?
4)	Developer: Performance is one, as I mentioned before. Also read http://canonical.org/~kragen/isinstance/ .
The PTL wanted it this way... see http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-11-03.log.html#t2016-11-03T
5)	Reviewer: What about hasattr?  Or try/except AttributeError?  Those should have performance equivalent to the original method call - and they have the bonus effect of being more forward-compatible (in case we add a NetworkInfoSomeOtherKindOfWrapper in the future that also lacks a wait method).
6)	Developer: maybe. Though there's really nothing to the forward-compatibility argument. Any future classes would subclass NetworkInfo, so they would have the wait method by virtue of the current proposal.
We can do whatever the nova core team wants. Need them to weigh in.
7)	Reviewer: I don't care about performance, I care about spaghetti code with isinstance or hasattr all over the place. Because invariably we'll add a new call to nw_info.wait() at some point that won't know it needs to do the isinstance or hasattr and it will fail at runtime because we'll have mocked out the wait() call in unit tests.
As noted, this is how it always worked before newton, so I'm inclined to just add this back in here. If there are concerns about it being removed again later, than make the comments in this method more forceful about why this is needed. But the unit tests should also cover it from being accidentially removed.
Source Code URL: https://review.opendev.org/#/c/393669/3..4/nova/network/model.py@470
19.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I96ad2fcf35eb1e79ecab006d76f04ba428d65186
Code Smell Term: swiss army knife
Code Smell Discussions: 
1)	Reviewer: This feels like another swiss army knife style function.  Here the thing to do is leave the code where it is or break the bits up into individual functions.
2)	Reviewer: Right. Those are three unrelated cases, why would we care to enclose them inside one particular function?
Source Code URL: https://review.opendev.org/#/c/359882/1/nova/virt/libvirt/driver.py@1946

1.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ibf0db6ad5b8367fc3267ac309516c08547d47e8c
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Will we have a new DB API method to get a BDM by it's UUID? Maybe that comes later in the series.
2)	Developer: An earlier version of this patch contained one, but I removed it as there's no currently planned user: it would be dead code right now. No reason we can't add one later if it's required, though.
Source Code URL: https://review.opendev.org/#/c/242602/24..25/nova/db/sqlalchemy/api.py@3736
2.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I8c814c756c7733669a8880ddc183a1b062cc55e0
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This looks like dead code
Source Code URL: https://review.opendev.org/#/c/519997/4/nova/api/openstack/extensions.py@a322
3.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I9f864455c69e1355a3cf06d7ba8b98fa3bcf619c
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This would be modifying the RPC return structure for anything that still uses this, which isn't cool. However, isn't this dead code now?
Source Code URL: https://review.opendev.org/#/c/495854/25..26/nova/scheduler/manager.py@58
4.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I75438ffb6cabf797aa98a93963107139a68e20b3
Code Smell Term: dead code
Code Smell Discussions: 
1)	Developer: I think this is also likely dead code.
2)	Developer: However, removing this could result in some weird behavior in the DB API filtering since there is no instances.fixed_ip column. And the server list schema allows additionalProperties so we won't fail on those.
3)	Reviewer: This seems fine as it is remapped to 'ip' @L2326.
4)	Reviewer: But yea it would not come to this point as schema will strip out this.
5)	Reviewer: However, removing this could result in some weird behavior in the DB API filtering since there is no instances.fixed_ip column. And the server list schema allows additionalProperties so we won't fail on those.
Sounds like we want to keep this so, thanks to those additionalProperties
Source Code URL: https://review.opendev.org/#/c/509819/1/nova/compute/api.py@2334
5.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I9a5dc8b603b5e4e0d37c59cf2749e3ffc217580c
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: The obj_make_compatible function on payload classes is basically dead code as we are not supporting backporting payload objects. I proposed a patch to remove this code: https://review.openstack.org/#/c/514943/
Source Code URL: https://review.opendev.org/#/c/514782/2..3/nova/notifications/objects/flavor.py@111
6.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I550c2b9b7f3eceac27fde253ba65fa6bb70fa875
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: this entire block is dead code now that you've moved this code to line 181 above.
2)	Developer: Ugh - rebase error.
Source Code URL: https://review.opendev.org/#/c/486215/10..11/nova/scheduler/filter_scheduler.py@231
7.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I391554d3904a5a60b921ef4714a1cfd0a64a25c2
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: What are we trying not to leak this to?
2)	Developer: I think leak here means having an undeleted bdm for a deleted instance. 
Destorying the bdm at this point in the db does no prevent us to send out the notification below as the in memory data of the bdm is still available. However I can move this loop after the instance.delete end notification if that makes function more logical.
3)	Reviewer: Moving it in this patch seems unnecessary and unrelated.
4)	Reviewer: This is likely dead code anyway, we delete the bdms when we delete the instance:
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1891
Source Code URL: https://review.opendev.org/#/c/483324/9..10/nova/compute/manager.py@723
8.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ieb4ae4605fee8fbf58de4c5efb3c00083b4bd62c
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: I still wondering why we cannot trigger this code path in the test. Is this dead code?
2)	Reviewer: this path is covered. See below.
Source Code URL: https://review.opendev.org/#/c/417882/7..8/nova/compute/manager.py@3816
9.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I1c9442eed850a3eb7ac9871fafcb0ae93ba8117c
Code Smell Term: dead code
Code Smell Discussions: 
1)	Developer: This is dead code, the same host tests call _resize_to_same_host_and_check_allocations, not this method.
Source Code URL: https://review.opendev.org/#/c/490085/5..6/nova/tests/functional/test_servers.py@1300
10.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Idffb8e0fd30acc6c5e79d0a96ffc9a5d112b9cb2
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Do we still need this call (and the actual function) now that we're querying libvirt directly? Seems like libvirt can be treated as the sole source of truth
2)	Developer: It's good point I need to check that
3)	Developer: I imagine your are right we should never be in such situation, but i feel scary to let the 'else' condition not handled.
That method is doing extra verifications in such case I guess we can't do better but I'm open for suggestion.
4)	Reviewer: Good point. How about we raise an exception here? If libvirt truly tells us the migration status then there's no reason to keep this around as it would be dead code. If it doesn't then that's a bug and we should highlight it as soon as possible, IMO
5)	Developer: So basically what you want to do is to set the status as failed, so we start a rollback ?
...hum yes I think it makes sense in such situation
6)	Reviewer: Yes, exactly. Something has clearly gone wrong and we should alert the user rather than trying to guess what they want
7)	Reviewer: This might be a guard when libvirt migration API will not raise an exception but gracefully end after failed migration.
However, I cannot provide a real case there. I'd say that if it fails it will be a corner case which is very unlikely. If this piece of code stays here, I'm okay, but I'm also okay with removing it.
Source Code URL: https://review.opendev.org/#/c/409261/5..7/nova/virt/libvirt/driver.py@6327
11.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Id5841c6f33247042deb88e2519503d65b52dc1dc
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This is dead code too.
Source Code URL: https://review.opendev.org/#/c/343734/9/nova/tests/unit/api/openstack/compute/test_simple_tenant_usage.py@102
12.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~stable/newton~I53bdcf8edf640e97b4632ef7a093f14a6e3845e4
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: I think you could leave this hunk here, right? If we resolved it above due to the change here, we should never need to run this. I know it kinda orphans this, but it's less change. You could add a comment to that effect without disturbing the code. I know you could argue less change vs. making the code internally more consistent, but I think I tend to prefer the former.
2)	Developer: Correct, the reason I changed this is because with the change above this block becomes dead code.
Source Code URL: https://review.opendev.org/#/c/468227/2/nova/compute/manager.py@a2677
13.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Iafb9ce4c1582715c6afac87cc9ae62e259f21b07
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This is dead code basically, don't need this check.
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/443951/10..11/nova/virt/libvirt/volume/vrtshyperscale.py@58
14.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Iafb9ce4c1582715c6afac87cc9ae62e259f21b07
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This is dead code since you're overwriting it next.
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/443951/13..14/nova/virt/libvirt/volume/vrtshyperscale.py@48
15.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Iee05dcf25155afbbfeecf9f186571b61a74353f8
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: I would rather we didn't merge dead code, we can keep that in gerrit history, etc, rather than merge it.
Source Code URL: https://review.opendev.org/#/c/404472/25..26/nova/compute/resource_tracker.py@528
16.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Iee05dcf25155afbbfeecf9f186571b61a74353f8
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Maybe raise would be best here?
I would rather we didn't merge dead code though. We will sure need this stuff later, but lets just move that to a follow on change that is marked as WIP.
Source Code URL: https://review.opendev.org/#/c/404472/25..26/nova/compute/resource_tracker.py@580
17.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Iab5f172cdef35645bae56b9b384e032f3160e826
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This is dead code because of the continue above.
2)	Developer: Oops, this was supposed to be dedented one level.
Source Code URL: https://review.opendev.org/#/c/426826/1..2/nova/objects/host_mapping.py@198
18.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Iee356c4dd097c846b6ca8617ead6a061300c83f8
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: I can see this optimization but this way is tricky and makes code unreadable.
So please add different test cases for a new feature even if it adds some duplicated code.
2)	Developer: In live migration cases, '_get_migration_body' (Line 53) is used.
So IMO, it is good to make and utilize this private method for consistency with live migration case.
3)	Reviewer: The consistency of unreadable tests is not reasonable for me..
4)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/408964/19..21/nova/tests/unit/api/openstack/compute/test_migrate_server.py@57
19.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I0a3d15f3e3d0d8d920a79b519e17e3228e99f293
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: Do you want to record an action for something that can blow up here? Seems wrong. I think we generally want to record the action before we start doing some actual work, which is usually before we perform an RPC cast/call to the compute.
2)	Developer: I was trying to avoid adding duplicated code for attach_volume and attach_volume_shelved_offloaded, so I put it in a more general place. BTW, do we want to differ the instance_actions for ATTACH_VOLUME and ATTACH_VOLUME_SHELVED_OFFLOADED?
3)	Reviewer: BTW, do we want to differ the instance_actions for ATTACH_VOLUME and ATTACH_VOLUME_SHELVED_OFFLOADED?
No, the API to get here is the same either way so distinguishing based on the shelved offloaded status would be confusing.
Source Code URL: https://review.opendev.org/#/c/517205/5..6/nova/compute/api.py@3604
20.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ia7b25092647515ad0f148deaba29818f9eb1f22b
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: When I see this patch first, I was curious why this patch makes more lines of code before even if this commit message says a cleanup.
This detail() and the above index() have duplicated code and the difference is just here "detail=True" only.
So how about defining the index() like
 def index(self, req, hypervisors, host_api, servicegroup_api, links=False, detail=False):
     ...
     if links:
         hypervisors_links = self._get_links(
             req, hypervisors_list, detail=detail)
     ...
and detail() could be like
 detail(self, req, hypervisors, host_api, servicegroup_api, links=False)
     return self.index(req, hypervisors, host_api, servicegroup_api, links=links, detail=True)
?
or just call index() with detail=True from nova/api/openstack/compute/hypervisors.py without this detail() definition.
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/335282/16..17/nova/api/openstack/compute/views/hypervisors.py@123
21.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I46baa952b6c3a1a4c5cf2660931f317cafb5757d
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: This is way off - you've got duplicated code, handlers for the same exception that do separate things, etc. You need to rework this
2)	Developer: I've a simpler version ready, just wanna settle on how to do the unit tests first.
Source Code URL: https://review.opendev.org/#/c/357190/10..11/nova/virt/libvirt/guest.py@302
22.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Icedd43888348184435faa0df4d9b5b655719f974
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: There was some discussion about deepcopy+update vs. duplicated code on microversioned json-schema on both Nova and Tempest sides.
We tend to prefer duplicated code because that would be readable for developers. Actually the above case is very simple json-schema but the readability seems less.
So it is a nice chance to implement it like
 index_query_schema_v210 = {
    'type': 'object',
    'properties': {
        {'user_id': parameter_types.multi_params({'type': 'string'})}
    },
    'additionalProperties': True
 }
 ..
2)	Developer: yea, for the short schema, maybe avoid to use 'deepcopy' is better. let me update it.
Source Code URL: https://review.opendev.org/#/c/398755/1..2/nova/api/openstack/compute/schemas/keypairs.py@107
23.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I902d75efb0bbe177680d7211c23235f42497e3fe
Code Smell Term: temporary field
Code Smell Discussions: 
1)	Reviewer: Given the next patch in the series which queries on this field, should we index it?
https://review.openstack.org/#/c/427902/
2)	Reviewer: No. It's only used as a temporary migration thing. There's no reason to add an index for a temporary field.
Source Code URL: https://review.opendev.org/#/c/427901/3..4/nova/db/sqlalchemy/models.py@180

1.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I2af45a9540e7ccd60ace80d9fcadc79972da7df7
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This clause seems important for resize to the same host scenario, but it is dropped in the latest patch. Why? If the new method `remove_provider_tree_from_instance_allocation()` is not designed for that same host scenario, that should be documented both in this function and the commit message explicitly.
2)	Developer: It was an old piece of dead code that wasn't cleaned up when resize started to move souce host allocations to the migration uuid. We have a set of functional tests for resize on same host that verifies this behavior and that the allocations are handled properly:
nova.tests.functional.test_servers.ServerMovingTests#test_resize_confirm_same_host
nova.tests.functional.test_servers.ServerMovingTests#test_resize_revert_same_host
3)	Reviewer: Ah, I missed that. The spec [1] says "instead of trying to double-allocate for an instance, and then having to subtract the source node/flavor from that allocation on success, we can simply operate on allocations atomically", which makes sense this is a dead code. I will look into this more closely. Sorry for the noise, but it is very good to know. Thank you.
[1] https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/migration-allocations.html
Source Code URL: https://review.opendev.org/#/c/606050/10/nova/scheduler/client/report.py@a1949
2.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I739c06bd02336bf720cddacb21f48e7857378487
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: We won't hit the compute API during a reschedule. Once we're in a cell we should assume we can't get out.
We could potentially do some cleanup in the cell conductor in the build_instances method which is where we get during a reschedule:
https://github.com/openstack/nova/blob/7125dcb9cb821faf3c68526ac34365a28141e480/nova/conductor/manager.py#L519
But it gets confusing having cleanup code strewn throughout both the compute manager and conductor, even though we do network cleanup in conductor if we've exhausted our retries:
https://github.com/openstack/nova/blob/7125dcb9cb821faf3c68526ac34365a28141e480/nova/conductor/manager.py#L613
Although that network cleanup code in conductor, which was added in 2015:
Ic670dd4dc192603c2faecf18e14ef59ebca9e420
Is probably dead code now since change Ib2abf73166598ff14fce4e935efe15eeea0d4f7d in compute makes us always deallocate networking before rescheduling.
Anyway, point is, I think we want to keep cleanup code local to compute *before* we reschedule if possible since that's where we know what is going on.
Source Code URL: https://review.opendev.org/#/c/587071/3..4//COMMIT_MSG@10
3.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I120a98cc4c11772f24099081ef3ac44a50daf71d
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Maciej was saying he thinks we can/should remove this but I'm not entirely sure why - if nothing changed why do we need to update the DB?
The scheduler HostManager uses the updated_at value here:
https://github.com/openstack/nova/blob/536acbfe0572f10ea84f330f2f29b07ca9279114/nova/scheduler/host_manager.py#L194
But I'm not sure that is really necessary since I40c17ed88f50ecbdedc4daf368fff10e90e7be11 when we stopped caching the host states globally in the scheduler. Meaning, I think we load up the HostState from the compute node data per request (unless you're using the CachingScheduler).
Anyway, that all seems like dead code at this point.
2)	Reviewer: Hmm, this logic changed in queens:
e2a18a37190e4c7b7697a8811553d331e208182c
Specifically:
https://review.openstack.org/#/c/518294/2/nova/compute/resource_tracker.py@807
3)	Developer: Hey, so I can confirm that if there is no change in resources (for example after dropping this double-updates with different consumptions) this method always return False.
As per IRC - if we don't care about 'update' timestamps in ComputeNode objects - for me its ok to leave it as it is here.
4)	Reviewer: Wouldn't that have been the case before though? If there were no changes on this node, the first _update and last _update should both return False for _resource_change, right? Or was there something in between that actually always updated the compute node and resulted in this always returning True even though none of the resource inventory/usage changed? I'd say just leave it because I have to think it was working the same way before unless you know of something different.
Source Code URL: https://review.opendev.org/#/c/520024/9/nova/compute/resource_tracker.py@928
4.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ic48087fdf283b3ba503294a944be91be0c338132
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: net_admin
2)	Developer: But tests pass for this one?
3)	Reviewer: Are you certain we're calling this in dsvm?
4)	Developer: I find it quite hard to tell if these are dead code or not. I guess we should ask Jay?
5)	Reviewer: These code paths are only hit for the defunct IVS vif plug type and the plug_ovs_hybrid() code path, which actually should not be used any more since os-vif handles OVS hybrid plugging.
Source Code URL: https://review.opendev.org/#/c/489438/6..7/nova/virt/libvirt/vif.py@579
5.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Icf948f6ee1c0da2327fb5eac61fec6e89ac30531
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: All of this is dead code now too (Sorry - I should have spotted it earlier). Also, I think 'get_firewall_required' is also dead
2)	Developer: Done
Source Code URL: https://review.opendev.org/#/c/534371/10/nova/virt/libvirt/vif.py@a275
6.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ib6d4a2d6b9072db42d11ecdde0950cf7a7781944
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Talking to Sahid on IRC and looking at how/when we call this. I think this might be dead code, as we have handling for vhostuser stuff in os_vif_util, which should mean that we aren't ever calling this anymore.
Source Code URL: https://review.opendev.org/#/c/484997/16..17/nova/virt/libvirt/vif.py@459
7.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~Ic9a0bda9314cc1caed993db101bf6f874c0a0ae8
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: I was going to comment that it seems like we should just skip all the marker lookup above if --reset is passed. However, I assume we do it here so we look it up and delete it. That makes L1122 kinda dead code if --reset is passed, but not a huge deal.
2)	Developer: Yea, the reason why I put the check after the look up is because we would anyways have to destroy the existing marker_mapping record from the previous run, else we might have two of such records later if I understand correctly.
Source Code URL: https://review.opendev.org/#/c/539501/4..5/nova/cmd/manage.py@1124
8.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I510136a7eb0a832dfe469cb68d06d1b9472d9ae4
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This is dead code, right?
Source Code URL: https://review.opendev.org/#/c/469784/14..15/nova/virt/fake.py@718
9.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I5f81393a5bb41e6a674369afb899d8a41bb2c3b4
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: Why isn't the wrapped attribute checked below when dealing with image_chunks? Is this new and if so, can you link to the change to glanceclient in which this is introduced? My point being, if one were to try and backport this fix, would this fail with older versions of glanceclient?
2)	Developer: Why isn't the wrapped attribute checked below when dealing with image_chunks?
See below.
 Is this new and if so, can you link to the change to glanceclient in which this is introduced? My point being, if one were to try and backport this fix, would this fail with older versions of glanceclient?
This will work with versions of glanceclient >= 2.6 [1]. If older branches use something different to this, we would need to use the earlier version of the patch. This seems to affect only Newton [2].
[1] https://github.com/openstack/python-glanceclient/commit/610177a779b95f931356c1e90b05a5bffd2616b3
[2] https://github.com/openstack/requirements/blob/stable/newton/upper-constraints.txt#L287
3)	Reviewer: So if we want this to be backportable, why don't we do a condicitional hasattr check on image_checks.wrapped? Something like:
if image_chunks is None or getattr(image_chunks, 'wrapped', None) is None:
    fail
4)	Developer: I didn't because the first assertion is dead code for the two most recent versions of nova and figured removing 'wrapped' as part of the backport process wouldn't be an issue. I can do this though if you'd rather not modify the backported patch?
5)	Reviewer: upper-constraints isn't what we'd base the glanceclient boundary on, we'd use global-requirements because that defines the minimum required version.
It looks like >=2.8 is the minimum required version of glanceclient going back to stable/pike. Ocata requires >=2.5 so we couldn't backport this to ocata without changes, but I'm not sure we need to backport it to ocata anyway given it's probably very latent anyway.
Source Code URL: https://review.opendev.org/#/c/526329/4..5/nova/image/glance.py@322
10.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I8cbfe296238976001e38997842059ec2f137f660
Code Smell Term: dead code
Code Smell Discussions: 
1)	Reviewer: This is dead code now.
Source Code URL: https://review.opendev.org/#/c/519483/5..6/nova/tests/unit/virt/xenapi/test_vm_utils.py@360
11.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I7e01f95d7173d9217f76e838b3ea71555151ef56
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: Splitting this into two separate methods is a bit confusing, because the schema is the same, the only difference is whether the links should be returned.
2)	Developer: To be honest, I'm not sure what the real rules on splitting method. An alternative approach is something like:
@wsgi.Controller.api_version("2.1", "2.53")  # noqa
@extensions.expected_errors(())
@validation.query_schema(schema_migrations.list_query_schema_v20,
                         "2.1", "2.53")
def index(self, req):
    if api_version_request.is_supported(req, min_version='2.23'):
        return self._index(req, add_link=True)
    else:
        return self._index(req)

I think maybe the previous one is more clearer, we can see clearly that:
with 2.1~2.22 call `self._index(req)` 
with 2.23~2.53 call `self._index(req, add_link=True)`
and also no need to check (api_version_request.is_supported) in any micro version.
Yeah, it's really add some duplicated code(such as the same expected_error and the same schema). I was a little hesitant before.
And then, I also have a look on other interfaces, such as keypair:
https://github.com/openstack/nova/blob/e48db05b0d5820d9c8838ee55dfacb04cf88289f/nova/api/openstack/compute/keypairs.py#L251
So, finally, I split this into two separate methods. Maybe the keypair's index is a bad example, Could you give me some advice on it?
Source Code URL: https://review.opendev.org/#/c/330406/41..42/nova/api/openstack/compute/migrations.py@116
12.	Code Change URL: https://review.opendev.org/#/q/openstack/nova~master~I3bbd5b95ecf9d096e662592c9b2e6ad37382fb49
Code Smell Term: duplicated code
Code Smell Discussions: 
1)	Reviewer: Related to my comment in the API code, I don't think we want to try and enforce a sort order before the new microversion. We only need to page if we have a limit or a marker, and before the new microversion we won't have either of those. That also means before the new microversion, the API shouldn't be sending sort_keys or sort_dirs.
So I think what we want is more something like this:
if limit or marker:
   # Determine default sort keys/direction
   sort_keys, sort_dirs = process_sort_params(sort_keys, sort_dirs,
                                               default_dir='desc')
   return sqlalchemyutils.paginate_query(...)
else:
   return query.all()
That way we only apply the sort key/dir paging logic if we're asked to (with the new microversion), otherwise we do what we did before.
2)	Developer: Ah, sorry for misunderstanding your means. Yeah, this approach is better than mine. Before patch submitted, I was entangled with something about which the old default sort order should be chosen with old microversion, actually, no need.
And other thing I want to make sure again, with new microversion, we need to keep the new default order(pass by the new micro version API) **without limit and marker**, right? 
So, sort_keys or sort_dirs also should be added in the condition:
if limit or marker or sort_keys or sort_dirs:
    sort_keys, sort_dirs = process_sort_params(sort_keys, sort_dirs, default_dir='des')
    return sqlalchemyutils.paginate_query().all()
else:
    return query.all()
If so, I have no questions left. Thanks for review again. : )
3)	Reviewer: if limit or marker or sort_keys or sort_dirs:
I'm not sure about adding sort_keys and sort_dirs here honestly.
With the old microversions, those will always be None because the REST API doesn't pass them down to the DB API.
With the new microversion, limit and marker are None by default if the user doesn't request them.
However, I assumed that with the new microversion we'd always impose our new default sort order, which is [created_at, id] in descending order. That's how we handle listing instances anyway, so I figured we'd do the same here with the new microversion. The DB API wouldn't control this, the REST API would by checking the microversion and if it's the new one, the REST API code passes down the sort_keys/sort_dirs regardless of whether or not limit/marker are specified. This way we'd have a consistent sort order with the new microversion even if you're not paging - and it would be consistent with the sort order when you do page.
4)	Reviewer: You know what, I think you're right.
The DB API will only call paginate_query if limit or marker or sort_keys or sort_dirs is specified, which in the old microversion will all be None. The new default sort order is controlled in the REST API.
Sorry for the confusion.
5)	Developer: Yes, I think you know what I mean. : )
With old microversion, query.all() will be used.
With new microversion, no matter whether the limit or marker are specified or not, sqlalchemyutils.paginate_query will be used. 
It's benefit to keep the new default order because paginate_query will work, otherwise we need some duplicated code to do some sort stuff before query.all() call.
Source Code URL: https://review.opendev.org/#/c/514904/12..13/nova/db/sqlalchemy/api.py@4948
